Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000028_owner-urn-ietf _Mon Aug 26 10:28:34 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA13688 for urn-ietf-out; Mon, 26 Aug 1996 10:28:34 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA13680 for <[e-mail]>; Mon, 26 Aug 1996 10:28:31 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA22256  (mail destined for [e-mail]); Mon, 26 Aug 96 03:51:44 -0400
Received: from legiron.acl.lanl.gov (transitory39.lanl.gov [128.165.7.161]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id BAA12622; Mon, 26 Aug 1996 01:51:38 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 26 Aug 1996 01:57:13 -0600
To: "Karen R. Sollins" <[e-mail]>, [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] concerns
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Karen R. Sollins (at least at 07:12 PM 8/23/96 -0400)

>Perhaps we would all be better
>off and have a higher probability of success, if we identified a
>smaller set of namespaces to which we were addressing our attention.
>By limiting the set of namespace schemes we might find that two
>additional concerns might be easier to address.

Sure, but I don't think it will be as much help as you hope.
The primary namespaces I am going after are:

1) CID - MIME ContentIDs.
2) ISO Formal Public Identifiers
   Best known in conjunction with SGML. These little gems have registered
   and unregistered naming authorities, as well as opaque strings.

Both of these have the notion of "opaque strings". Almost any
sort of structural info can be buried in there. That is why I
think we don't achieve much restriction on allowed syntax and
structure by focussing on a small number of name spaces.

In addition to those two main namespaces, there are a few others
that I would like to see us tackle once the first two are
working reasonably well. They are:

3) SICI - Serial Item Contribution Identifier
   Used for identifying journal articles - ISSNs only identify the journal,
   not articles in a journal issue.
4) ISBN - International Standard Book Number
5) ISAN - International Standard Audiovisual Number
6) ISWC - International Standard Work Code  (Music IDs)
   There is a lot of good content already identified with these schemes.
7) OIDs - ISO Object Identifiers
   Lots of things use OIDs as the naming authority part. Constructed OIDs
   allow an opaque ASN.1 "thing" to be appended to the hierarchical
   identifier.
8) http, ...
   NAPTR rewriting also provides a way for us to retrofit replication of
   resources and resolvers onto the existing URL pseudo-namespaces. It is
   less than perfect because there is no good way to ask for the NAPTR
   and/or A records for a domain name, but it is there.

>1) With foreknowledge of some syntactic constraints on URN schemes, we
>could reduce the probability of chaos from the otherwise uncontrolled
>regular expressions needed to parse and transform aspects of schemes.
>Although only a very small number of people have been commenting on
>the mailing list, I heard a great deal of concern about this in
>Montreal.

As mentioned above, there are no syntactic constraints to exploit
in "opaque strings".

What I heard in Montreal were expressions of concern about the
use of rewriting rules in general, not just regular-expression
based ones. I also had the sense that people were of the
opinion that, worrisome as it might be, this level of power seemed
to be needed to meet the requirements.

>2) With less complexity in the overall namespace structuring,
[...]

Again, I doubt that we will see any significant reductions in
complexity after we take a look at the things that people will do
in opaque strings. Those strings will undoubtably have lots of
structure in them, and it will not necessarily follow a simple
hierarchy. As an example, my lab already uses technical report
identifers like:
                   LA-UR-96-0023

LA = Los Alamos
UR = Unclassified Report. We have a number of different report series,
so those characters will change depending on the report series. That is
one place where delegation might occur.
96 = year of publication. I assume we will change to 4 digits RSN. :-)
     This year is another bit of significant info that might be used.
0023 = sequentially assigned number

These are existing identifiers that we at LANL would like to continue
to use, and I happen to think that it is a very reasonable thing for us
to do. I would oppose any effort in this group to limit what people might
be able to assign in their opaque strings.

[With simpler names,]
>migrating to a future set of mechanisms that do not involve regular
>expressions and the DNS might be manageable.

I don't think we can refuse to consider the class of namespaces that
use opaque strings. If we can't eliminate that class of namespaces,
I don't think we can reasonably achive significant simplification in
the names we have to resolve. Preventing people from assigning the
names of their choice pushes expense and effort onto others.

>Again, there was
>significant concern expressed about this in Montreal, although not on
>the mailing list since then.  This is a problem that is not addressed
>in the NAPTR related papers, but should be central to any plan that is
>proposed.

I don't recall much discussion of the migration issue during the BOF. What
I recall is that people were concerned about rewrite rules because they
get hairy over time. The topic of being locked into a rewrite-based
system because of its power was raised by Lewis, I think, in his
presentation but I can't recall it being discussed extensively.
(I could be wrong on this - Lewis came up shortly after I finished
and it takes me awhile to switch from speaker-mode to audience-mode).

You are correct that migration to future resolution systems is not addressed
in the NAPTR draft. I think that document should be a tight specification
of the NAPTR record format and usage. Migration should be (IMHO) handled
in the framework draft. Even there, I don't know that I would regard it
as central. There are other areas of concern, such as security,
replication, and maybe even rights management, that are equally important.
By definition, these concerns have a more pressing time frame than
migration.

We certainly don't want to do things now that are going to come back to
haunt us. Neither do we want to start with such a restricted system that
it can't accomplish its purpose. If we want URNs to start taking over
for URLs in order to achive their benefits, we have to offer a significant
advantage over URLs for J. Random Publisher. I think we have two shots at
that. The first is that Netscape, Microsoft, ... would really like a way to
transparently direct users to mirror sites instead of having the current
hack of listing 10 sites. Our second
chance is by accomodating namespaces such as ISBN that have a lot of
existing, high-quality, content. If we shut ourselves out of either of
those markets, URNs will probably not succeed.

Ugh. Its late - I'm going to bed.

Best regards,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"